home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 11⁄3⁄89 / 0011-PerformCommand Probl-Nov89 < prev    next >
Encoding:
Text File  |  1989-11-03  |  2.1 KB  |  74 lines  |  [TEXT/GEOL]

  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    1146035                         2-Nov-89        12:10
  4.  
  5. From:   D2086                           Efficient Field Svc, C Faith,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    PerformCommand Problems
  10.  
  11. There is a slight problem with how commit and doit are handled by
  12. TApplication.PerformCommand.
  13.  
  14. Specifically, I have a command that can be both Undoable and not Undoable
  15. depending on exactly what happens in TrackMouse.
  16.  
  17. Ideally I would like to be able to have the DoIt method set the state of
  18. fCanUndo to the correct value depending on whether the actions of DoIt are
  19. undoable or not.
  20.  
  21. Presently this decision cannot be in DoIt because TApplication.Perform Command
  22. executes in the order:
  23.  
  24. saveCmd :=  command.fCausesChange | command.fCanUndo;
  25.  
  26. IF saveCmd THEN
  27.     CommitLastCommand;
  28.  
  29. ......
  30.  
  31. command.DoIt;
  32.  
  33. IF saveCmd THEN
  34.     BEGIN
  35.     gLastCommand := command;
  36.     command.fCmdDone := TRUE;
  37.     END;
  38.  
  39. Hence if fCanUndo is False then even if Doit sets fCanUndo to TRUE:
  40. gLastCommand is not Set
  41. command.fCmdDone is not set to TRUE
  42. CommitLastCommand is not called
  43.  
  44. because the value of saveCommand is set before DoIt.
  45.  
  46. Why could saveCommand not be computed after DoIt and CommitLastCommand be
  47. deferred?  Perhaps there is some concern that DoIt relies on the
  48. previousCommand having been committed?  I do not know whether this is a more
  49. valid generalization than assuming that DoIt will not change fCanUndo.
  50.  
  51. Is there something wrong with changing fCanUndo in DoIt?  (conceptually at
  52. least, it is wrong now because it does not work)
  53.  
  54. At the least PerformCommand could check
  55.  
  56. { CommitLastCommand would have set gLastCommand to NIL if already executed }
  57. IF gLastCommand <> NIL and command.fCanUndo THEN
  58.     BEGIN
  59.     CommitLastCommand;
  60.     saveCommand := TRUE;
  61.     END;
  62.  
  63. right after DoIt, this would have the effect of enabling changes in fCanUndo
  64. while still ensuring that if the last command's state should be committed
  65. before DoIt it would be.  I am not sure that this is even necessary.
  66.  
  67. Anyone have any thoughts on this?
  68.  
  69. - Curtis
  70.  
  71.  
  72.  
  73.  
  74.